• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    Implementations of the present invention include receiving, from a first account, a digitally signed copy of a commitment amount of a first amount of a transaction amount generated based on a first random number, the first balance transfer amount, and the first random number encrypted using a public key from the first account, a second amount from the balance transfer, and a second random number encrypted using a public key from the second account and a set of values generated based on one or more selected random numbers. the first account determines whether the first amount and the second amount are equal and whether the first random number and the second random number are the same based on the set of values, and updates the balance of the first account and a balance of the second account based on the first amount of the balance transfer.
    公开号:BR112019008148B1
    申请号:R112019008148-8
    申请日:2018-11-07
    公开日:2021-08-10
    发明作者:Baoli Ma；Wenbin Zhang
    申请人:Advanced New Technologies Co., Ltd；
    IPC主号:
    专利说明:

    FIELD OF THE INVENTION
    [001] The present invention relates to computer-implemented methods for privacy-protected verification of trust protocol transactions without user confirmation, interaction and disclosure of transaction amounts or account balances. BACKGROUND OF THE INVENTION
    [002] Blockchain networks, which may also be referred to as trusted protocol systems, consensus networks, distributed accounting system networks, or trust protocol, allow participating entities to securely store data and immutable. A trust protocol can be described as a transaction accounting system and multiple copies of the ledger are stored across the trust protocol network. Examples of types of trust protocols can include public trust protocols, authorized trust protocols, and private trust protocols. A public trust protocol is open for all entities to use the trust protocol and participate in the consensus process. An authorized trust protocol is similar to a public trust protocol, but only open to entities with permission to participate. A private trust protocol is provided for a specific entity, which centrally controls read and write permissions.
    [003] Trust protocols are used in cryptocurrency networks, which allow participants to carry out transactions to buy/sell goods and/or services using a cryptocurrency. A common cryptocurrency includes Bitcoin. In cryptocurrency networks, record keeping models are used to record transactions between users. Examples of record keeping models include the unspent transaction output (UTXO) product model and the account balance model. In the UTXO model, each transaction spends the product of previous transactions and generates new products that can be spent on subsequent transactions. A user's unused transactions are tracked and a balance the user has is calculated as the sum of all the user's unused transactions. In the account balance model, each user's account balance is tracked as a global state. For each transaction, an expense account balance is checked to ensure that it is greater than or equal to the transaction amount. This is comparable to traditional banking.
    [004] A trust protocol ledger includes a series of blocks, each of which contains one or more transactions performed on the network. Each block can be explained by analogy to a ledger page, while the trust protocol itself is a complete copy of the ledger. Individual transactions are confirmed and added to a block, which is added to the trust protocol. Copies of the trusted protocol ledger are replicated across nodes in the network. In this way, there is a global consensus on the status of the trust protocol. Furthermore, the trust protocol is open for all nodes to see, at least in the case of public networks. To protect the privacy of trusted protocol users, encryption technologies can be implemented.
    [005] Under the account model, commitment schemes can be used to hide amounts that both parties to a transaction commit to. Commitment schemes can arise from the need for parties to commit to a choice or value and then later communicate that value to the other parties involved. For example, in an interactive Pedersen Commitment, party A can commit a transaction amount t by sending a commitment value PC(r,t) which is generated based on the random value r. The commitment amount is generated and party B can only reveal the transaction amount t by getting the random number r. DESCRIPTION OF THE INVENTION
    [006] Embodiments of the present invention include computer-implemented methods for privacy-protected verification of trust protocol transactions without user confirmation, interaction and disclosure of transaction amounts or account balances. More particularly, embodiments of the present invention are intended to validate transactions between trusted protocol users based on compromise schemes and homomorphic cryptography without revealing transaction amount, account balances or random numbers to generate compromises with other protocol nodes reliable.
    [007] In some embodiments, actions include receiving, from a first account, a digitally signed copy of a commitment amount of a first amount of a transaction amount to be transferred from a first account to a second account generated with based on a first random number, the first balance transfer amount, and the first random number encrypted using a public key from the first account, a second balance transfer amount, and a second random number encrypted using a public key from the second account, a or more range proofs and a set of values generated based on one or more selected random numbers; verifying a digital signature corresponding to the digitally signed copy using a public key of the first account corresponding to a private key used to generate the digital signature; determine that one or more gap tests prove that the balance transfer amount is greater than zero and less than or equal to a balance of the first account; determining whether the first amount and the second amount are the same and whether the first random number and the second random number are the same based on the set of values; and updating the balance of the first account and a balance of the second account based on the first amount of the balance transfer if the first amount and the second amount are the same and the first random number and the second random number are the same. Other embodiments include corresponding computer systems, apparatus and programs configured to perform the actions of the methods encoded in computer storage devices.
    [008] These and other embodiments may each optionally include one or more of the following features: the tradeoff value is generated using a tradeoff scheme that is homomorphic; the compromise scheme is a Pedersen compromise scheme; the first balance transfer amount and the first random number are encrypted using the public key of the first account based on a probabilistic homomorphic (HE) encryption algorithm and where the second balance transfer amount and a second random number are encrypted using the public key of the second account based on the probabilistic algorithm HE; the probabilistic HE algorithm is an Okamoto-Uchiyama HE algorithm; the selected random numbers are represented by r*, t*, z1* and z2* and the selected random numbers are used to generate a, b, c and d, where a = r* + xr, b = t* + xt, c = z1* + xz1, and d = z2* + xz2, is the first random number, up to the first balance transfer amount, x is a scatter value; the set of values is additionally generated based on C, D and E, where C = gr*ht*, D = u2r*v2z1*, E = u2t*v2z2*, where g, h, u2 and v2 are generators of a elliptic curve and where x is generated based on dispersion C, D and E; the first amount and the second amount are determined to be the same and the first random number and the second random number are determined to be the same based on the properties of probabilistic HE; the first amount and second amount are determined to be the same and the first random number and second random number are determined to be the same if gahb = CTx, u2av2c = DZ_B1x, and u2bv2d = EZ_B2x, where T = grh is the value balance transfer amount commitment, Z_B1 = u2rv2z1, Z_B2 = u2tv2z2, and where z1 and z2 are random numbers used to encrypt the second balance transfer amount and second random number based on the probabilistic HE scheme; and updating the balance of the first account and a balance of the second account is performed based on HE.
    [009] The present invention also provides one or more computer-readable, non-transient storage media coupled to one or more processors and having instructions stored therein that, when executed by the one or more processors, cause the one or more processors perform operations in accordance with realizations of the methods provided herein.
    [010] The present invention further provides a system for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with realizations. of the methods provided here.
    [011] It is appreciated that the methods in accordance with the present invention may include any combination of the aspects and features described herein. That is, the methods according to the present invention are not limited to the combinations of features and features specifically described herein, but also include any combination of the features and features provided.
    [012] Details of one or more embodiments of the present invention are presented in the attached figures and in the description below. Other features and advantages of the present invention will be apparent from the description and figures, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS
    [013] Figure 1 represents an example of an environment that can be used to perform embodiments of the present invention.
    [014] Figure 2 represents an example of conceptual architecture according to embodiments of the present invention.
    [015] Figure 3 represents an example of privacy-protected validation method of a trust protocol transaction based on homomorphic cryptography according to embodiments of the present invention.
    [016] Figure 4 represents an example of trust protocol transaction based on homomorphic cryptography according to embodiments of the present invention.
    [017] Figure 5 represents another example of method of validation protected by privacy of a trust protocol transaction based on homomorphic cryptography according to embodiments of the present invention.
    [018] Figure 6 represents another example of trust protocol transaction based on homomorphic cryptography according to embodiments of the present invention.
    [019] Figure 7 represents an example of a process that can be performed according to embodiments of the present invention.
    [020] Figure 8 represents another example of a process that can be performed according to embodiments of the present invention.
    [021] Like reference symbols in the various drawings indicate like elements. DESCRIPTION OF ACHIEVEMENTS OF THE INVENTION
    [022] Embodiments of the present invention include computer-implemented methods for privacy-protected verification of trust protocol transactions without user confirmation, interaction and disclosure of transaction amounts or account balances. More particularly, embodiments of the present invention are intended to validate transactions between trusted protocol users based on compromise schemes and homomorphic cryptography (HE) without revealing transaction amount, account balances or random numbers to generate compromises for others Trust protocol nodes.
    [023] To provide additional context for embodiments of the present invention, and as introduced above, trust protocol networks, which may also be referred to as consensus networks (eg, composed of peer-to-peer nodes), accounting system distributed, or simply trusted protocol, allow participating entities to conduct transactions and store data securely and immutably. A trust protocol can be provided as a public trust protocol, a private trust protocol, or a consortium trust protocol. Embodiments of the present invention are described in more detail herein with reference to a publicly trusted protocol, which is public among participating entities. It is contemplated, however, that the embodiments of the present invention can be carried out in any appropriate type of trusted protocol.
    [024] In a publicly trusted protocol, the consensus process is controlled by nodes of the consensus network. For example, hundreds, thousands, and even millions of entities can participate in a public trust protocol, each of which operates at least one node in the public trust protocol. Thus, the public trust protocol can be considered a public network in relation to the participating entities. In some examples, most entities (nodes) must sign all blocks for the block to be valid and added to the trust protocol. An example of a public trust protocol includes the trust protocol used in the Bitcoin network, which is a peer-to-peer payment network (cryptocurrency network). Although the term trust protocol is commonly referred to by hand with the Bitcoin network, as used herein, trust protocol generally refers to ledgers distributed without particular reference to the Bitcoin network.
    [025] In general, a public trust protocol supports public transactions. A public transaction is shared with all nodes within the trust protocol, and the trust protocol ledger is replicated across all nodes. In other words, all nodes are in a perfect state of consensus regarding the trust protocol. To reach consensus (eg, agreement to add a block to a trusted protocol), a consensus protocol is implemented within the trusted protocol network. An example consensus protocol includes, without limitation, proof of work (POW) implemented on the Bitcoin network.
    [026] The embodiments of the present invention are described in greater detail herein in view of the above context. More particularly, and as introduced above, embodiments of the present invention are intended to validate transactions between trust protocol users based on commitment and HE schemes without revealing transaction amount, account balances or random numbers to generate commitments to other trusted protocol nodes.
    [027] According to the embodiments of the present invention, trust protocol transactions can be validated and recorded in a trust protocol (ledger) based on commitment, without revealing the transaction account balance, the transaction amount or the random number used to generate the appointment. A commitment scheme, such as the Pedersen (PC) commitment, can be used to generate a commitment of a transaction amount using a random number. Transaction amount and random number can be encrypted using probabilistic or deterministic HE. Transaction amount and random number can also be used to generate a set of values as evidence to validate the transaction based on HE properties. The transaction commitment, encrypted transaction amount, encrypted random number and proofs can be used by a trusted protocol node to verify that the transaction is valid without the account balance, transaction amount or random number being revealed.
    [028] Figure 1 represents an example of environment (100) that can be used to perform embodiments of the present invention. In some examples, the example environment (100) allows entities to participate in a public trust protocol (102). The example environment (100) includes computing systems (106, 108) and a network (110). In some examples, the network (110) includes a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof, and connects web sites, user devices (eg, computing devices ) and secondary systems (back-end). In some examples, the network (110) can be accessed through a wired and/or wireless communication connection.
    [029] In the example described, the computing systems (106, 108) can each include any appropriate computing system that allows participation as a node in the public trust protocol (102). Examples of computing devices include, without limitation, a server, a desktop computer, a laptop computer, a tablet computing device, and a smart phone. In some examples, computing systems (106, 108) host one or more computer-implemented services to interact with the publicly trusted protocol (102). For example, the computing system (106) may host computer-implemented services of a first entity (e.g., user A), such as a transaction management system that the first entity uses to manage its transactions with one or more others. entities (for example, other users). The computing system (108) may host computer-implemented services of a second entity (e.g. user B), such as a transaction management system that the second entity uses to manage its transactions with one or more other entities (e.g. , other users). In the example in Figure 1, the public trust protocol (102) is represented as a peer-to-peer network of nodes, and the computing systems (106, 108) provide nodes of the first entity and second entity, respectively, that participate. in the public trust protocol (102).
    [030] Figure 2 represents an example of conceptual architecture (200) according to embodiments of the present invention. The conceptual architecture (200) includes an entity layer (202), a hosted services layer (204), and a publicly trusted protocol layer (206). In the illustrated example, the entity layer (202) includes three entities, Entity_1 (E1), Entity_2 (E2) and Entity_3 (E3), each entity having a respective transaction management system (208).
    [031] In the illustrated example, the hosted services layer (204) includes trusted protocol interfaces (210) for each transaction management system (208). In some examples, a respective transaction management system (208) communicates with a respective trusted protocol interface (210) over a network (e.g., the network (110) of Figure 1) using a communication protocol ( for example, secure hypertext transfer protocol (HTTPS)). In some examples, each trusted protocol interface (210) provides a communication link between a respective transaction management system (208) and the trusted protocol layer (206). More particularly, each trust protocol interface (210) allows the respective entity to perform transactions registered in a trust protocol network (212) of the trust protocol layer (206). In some examples, communication between a trusted protocol interface (210), and the trusted protocol layer (206) is conducted using remote procedure calls (RPCs). In some examples, trust protocol interfaces (210) “host” trust protocol nodes to respective transaction management systems (208). For example, the trust protocol interfaces (210) provide the application programming interface (API) for accessing the trust protocol network (212).
    [032] As described here, the Trusted Protocol Network (212) is provided as a peer-to-peer network including a plurality of nodes (214) that immutably record information in a Trusted Protocol (216). Although a single trust protocol (216) is schematically represented, multiple copies of the trust protocol (216) are provided, and are maintained across the trust protocol (212). For example, each node (214) stores a copy of the trusted protocol (216). In some embodiments, the trust protocol (216) stores information associated with transactions that are performed between two or more entities participating in the public trust protocol.
    [033] Figure 3 represents an example method (300) of validation protected by privacy of a trust protocol transaction based on HE according to embodiments of the present invention. At a high level, the example method (300) is performed by a user node A (302), a user node B (not shown in Figure 3), and a trust protocol node (304), also referred to as a consensus node. A transaction, such as a transfer of value, can be made from user node A (302) to user node B. To protect account privacy, user node A (302) can generate a commitment from a transaction amount t using a commitment scheme, such as PC, based on a random number r. Appointment generated using PC can be expressed as PC(r,t). User node A (302) can also encrypt the random number using HE based on a public key of user node B. This can be expressed as HE(r). A ciphertext of the transaction amount t, expressed as (PC(r,t), HE(r)) can be transmitted to user node B. After receiving the ciphertext, user node B can decrypt the number r random using a private key. User node B can use the random number r to decipher the transaction amount t. To prove the validity of the transaction, the trust protocol node (304) can compare the random number in the pledge and the encrypted random number using HE. If the random numbers match, the transaction is determined to be valid by the trust protocol node (304) with zero knowledge of the transaction data. More details of the example method (300) are discussed in the following description of Figure 3.
    [034] At (306), user node A (302) generates a commitment value of a transaction amount based on a first random number, and encrypts, based on HE, a second random number using a public key of the user node A (302) and a third random number using a public key from user node B. The first random number, second random number, and third random number can be the same random number r used to generate an appointment from a transaction amount t using a commitment scheme. In some embodiments, the commitment scheme can have a double exponential shape, such as PC. Using PC as a non-limiting example, the compromise value generated by the first random number r can be expressed as PC(r,t) = grht, where g and h can be generators of an elliptic curve, PC(r,t)is a scalar multiplication of curve points, and up to the transaction amount to which it is committed. It should be understood that other HE-based commitment schemes such as Okamoto-Uchiyama (OR) HE, and Boneh-Goh-Nissim HE can also be used to generate the commitment value.
    [035] The second random number encryption r encrypted using the public key of user node A (302) can be expressed as HE_A(r). Encryption of the third random number r encrypted using user node B's public key can be expressed as HE_B(r).
    [036] In some embodiments, public key cryptography HE can be a deterministic HE that can be obtained from probabilistic HE schemes, such as Paillier HE, Benaloh HE, OR HE, Naccache-Stern HE, Damgard-Jurik HE, or Boneh-Goh-Nissim HE, setting the random number to a fixed value. In some embodiments, deterministic HE schemes that satisfy the linear properties that HE(a + b) = HE(a) + HE(b) and HE(ab) = HE(b)a, where a and b are plaintext text used for HE, can be used for the present invention.
    [037] In some examples, T = PC(r,t), T' = HE_A(r) and T" = HE_B(r), and the transaction amount ciphertext can be expressed as (T, T', and T”). The transaction can be determined to be valid if the conditions in the example are met. First, the transaction amount is greater than or equal to 0 and less than or equal to an account balance s_A of user node A (302). Second, the transaction is digitally signed by user node A's private key (302), private key to prove that the transaction is authorized by user node A (302). Third, the random number r in the compromise PC(r,t) is the same as r encrypted in the ciphertext HE_A(r), and HE_B(r) using the public keys of user node A (302) and user node B, respectively.
    [038] In some embodiments, the ciphertext can also be separated as ciphertext from an amount sent (t'), which can be expressed as (PC(r',t'), HE_A(r')), and a ciphertext of an amount received (t”), which can be expressed as (PC(r”, t”), HE_B(r”)). In such cases, the amount sent t’ also needs to be determined to equal the amount received t” to validate the transaction.
    [039] In (308), user node A (302) generates one or more interval proofs. In some embodiments, interval proofs may include an RP1 interval proof to show that the transaction amount is greater than or equal to zero, and an RP2 interval proof to show that the transaction amount is less than or equal to a balance of user node A account.
    [040] In (310), user node A (302) generates a set of values using HE based on one or more selected random numbers. The set of values, denoted Pf, may include proofs used to prove that the random number r in the compromise PC(r,t) is the same as r encrypted in the ciphertext HE_A(r) and HE_B(r) using the public keys of user node A (302) and user node B, respectively. In some embodiments, two random numbers r1 and t1 can be selected to compute another set of ciphertexts from t1 denoted as (T1, T1', T1"), where T1 = gr1ht1, T1' = HE_A(r1), T1" = HE_B(r1). Two additional proofs r2 and t2 can be calculated as r2 = r1 + xr, t2 = t1 + xt, where x is the dispersion of T1, T1’ and T1”. The set of values can be denoted as Pf = (T1, T1’, T1”, r2, t2).
    [041] In (312), user node A (302) uses its private key to digitally sign the ciphertext (T, T', T"), the ciphertext (T1, T1', T1"), r2 , t2, the interval proofs RP1 and RP2, and the public keys of user node A (302), and user node B. The digital signature added by user node A (302) can be used to show that the transaction is authorized by user node A (302). The digitally signed copy is submitted to the trusted protocol network at (314).
    [042] At (316), the trust protocol node (304) verifies the digital signature using a public key from user node A (302). The trust protocol node (304) can be a consensus node that can prove the validity of transactions in the trust protocol network. If the trusting protocol node (304) cannot verify the digital signature of user node A (302) using the public key, the digital signature may be determined to be incorrect and the transaction may be denied. In some embodiments, the trust protocol node (304) may also include a dual anti-spend mechanism. The trust protocol node (304) can check whether the transaction has already been performed or recorded. If the transaction has already been executed, the transaction can be rejected. Otherwise, transaction validation can continue.
    [043] In (318), the trust protocol node (304) checks the one or more gap probes. For example, RP1 interval proof can be used to prove that the transaction amount is greater than or equal to zero, and RP2 interval proof can be used to prove that the transaction amount is less than or equal to an account balance. of user node A (302).
    [044] At (320), the trust protocol node (304) determines that the first random number, the second random number, and the third random number are the same based on the set of values. In some embodiments, the determination includes determining whether the example conditions gr2ht2 = TxT1, HE_A(r2) = T’xT1’ and HE_B(r2) = T”xT1” are true based on the properties of the deterministic HE, as discussed above. If true, it can be indicated that the random number in the compromise is the same as the random numbers homomorphically encrypted using the public keys of user node A (302) and user node B, and the transaction is valid.
    [045] At (322), the trust protocol node (304) updates the account balances of user node A (302), and user node B. Balance updates can be performed based on the properties of HE without revealing the account balances of user node A (302) or user node B. The update of account balances is described in more detail here with reference to Figure 4.
    [046] Figure 4 represents an example of trust protocol transaction (400) based on HE according to embodiments of the present invention. As shown in the trust protocol transaction example (400), a user node A (402) transfers a transaction amount t to a user node B (406). Prior to the transaction, user node A (402) has an account balance of s_A and user node B (406) has an account balance of s_B.
    [047] Using the encryption schemes and transaction process described here with reference to Figure 3 as an example, the account balance s_A can be encrypted using a PC based random number r_A and the random number r_A can be encrypted based on HE . The ciphertext of account balance s_A can be expressed as (S_A, S’_A) = (gr_Ahs_A, HE_A(r_A)), where g and h can be generators of an elliptic curve to generate the PC of account balance s_A. Likewise, an account balance s_B from user node B (406) can be encrypted using a PC-based random number r_B. The ciphertext of account balance s_B can be expressed as (S_B, S’_B) = (gr_Bhs_B, HE_A(r_B)).
    [048] At (404), user node A (402) can add digital signature to the proofs used to validate the transaction, and send the digitally signed copy to the trusted protocol network (408). As described above with reference to Figure 3, the proofs may include the transaction amount ciphertext (T, T', T”), one or more interval proofs (RP1, RP2) and other proofs (T1, T1' , T1”, r2, t2).
    [049] After the transaction, the account balance of user node A (402) can be expressed as s_^ - t', and the account balance of user node B (406) can be expressed as s_B + t” , where t' is the amount sent by user node A (402) and t" is the amount received by user node B. The ciphertext of the account balance of user node A (402) after the transaction can be expressed as (S_A/T, S'_A/T') and the ciphertext of the user node B account balance (406) after the transaction can be expressed as (S_B * T, S'_B * T”). As S_A, S'_A, S_B, S'_B, T, T' and T" are each encrypted using HE with double exponential form, addition and subtraction can be performed in their encrypted form without deciphering the values of unencoded text.
    [050] Figure 5 represents another example of method (500) of validation protected by privacy of a trust protocol transaction based on HE according to embodiments of the present invention. At a high level, the example method (500) is performed by a user node A (502), a user node B (not shown in Figure 5) and a trust protocol node (504), which can be referred to as a consensus node. A transaction, such as a transfer of value, can be made from user node A (502) to user node B. To protect account privacy, user node A (502) can generate a commitment of the amount transaction t using a commitment scheme, such as PC, based on a random number r. Appointment generated using PC can be expressed in PC(r,t). User node A (502) can also encrypt the transaction amount t and the random number r using HE which has a double exponential form, such as OR.
    [051] A ciphertext of transaction amount t can be submitted to the trusted protocol network. After receiving the ciphertext, the trust protocol node (504) can determine whether the random number r hidden in the PC matches the random number r encrypted in the OU using the public keys of user node A (502) and the node of user B, respectively. In addition, the trust protocol node (504) can determine whether the transaction amount t hidden in the PC matches the transaction amount t encrypted in the OR using the public keys of user node A (502) and user node B , respectively. If both random numbers and transaction amounts match, the transaction can be determined to be valid by the trusting protocol node (504) with zero knowledge of the transaction data.
    [052] At (506), user node A (502) generates a commitment value of a first transaction amount based on a first random number, and the first transaction amount and the first random number encrypted using a key public of user node A (502). A second transaction amount and a second random number are encrypted using a public key from user node B. The first transaction amount and the second transaction amount can be the same amount t. The first random number and the second random number can be the same random number r used to generate a commitment of transaction amount t using a commitment scheme. In some embodiments, the commitment scheme can have a double exponential shape, such as PC. Using PC as an example, the compromise value generated by the first random number r can be expressed as PC(r,t) = grht, where g and h can be generators of an elliptic curve, PC(r,t)is a scalar multiplication of curve points, and up to the transaction amount that is committed. It should be understood that other HE-based commitment schemes such as OR HE and Boneh-Goh-Nissim HE can also be used to generate the commitment value.
    [053] User node A (502) may also encrypt the first random number and the first transaction amount using user node A's public key (502) and encrypt the second random number and second transaction amount using the public key of user node B. In some embodiments, the encryption of random numbers and transaction amounts may be based on probabilistic HE, such as OR. Using OR as an example, encrypting the first random number and the first transaction amount using user node A's public key (502) can be expressed as OU_A(r) = u1rv1y1 and OU_A(t) = u1tv1y2, respectively, where u1 and v1 are generators on the elliptic curve and y1 and y2 are random numbers used to generate OR_A(r) and OR_A(t). The second encrypted random number and second transaction amount can be expressed as OU_B(r) = u2rv2z1 and OU_B(t) = u2tv2z2, respectively, where u2 and v2 are generators on the elliptic curve and z1 and z2 are random numbers used to generate OU_B( r) and OR_B(t), respectively. Probabilistic OR satisfies the property that OR(a + b) = OR(a) * OR(b), where a and b are the uncoded text used for OR.
    [054] The ciphertext of transaction amount t can be expressed as (PC(r,t), OR_A(r), OR_A(t), OR_B(r), OR_B(t)). The transaction can be determined to be valid if the following example conditions are met. First, the transaction amount is greater than or equal to 0 and less than or equal to the account balance s_A of user node A (502). Second, the transaction is digitally signed using user node A's private key (502), private key to prove that the transaction is authorized by user node A (502). Third, the random number r in the commitment PC(r,t) is the same as r encrypted in the ciphertext OR_A(r) and OR_B(r) using the public keys of user node A (502) and user node B , respectively. Fourth, the transaction amount t in the commitment PC(r,t) is equal to the t encrypted in the OR_A(t) and OR_B(t) ciphertext using the public keys of user node A (502) and user node B , respectively.
    [055] In some embodiments, the ciphertext may also be separated as ciphertext from an amount sent (t'), which can be expressed as (PC(r', t'), OR_A(r'), OR_A( t')), and a ciphertext of an amount received (t”), which can be expressed as (PC(r”, t”), OR_B(r”), OR_B(t”)). In such cases, the amount sent t’ also needs to be determined to equal the amount received t” to validate the transaction.
    [056] In (508), user node A (502) generates one or more interval proofs. In some embodiments, interval proofs may include an RP1 interval proof to show that the transaction amount is greater than or equal to zero, and an RP2 interval proof to show that the transaction amount is less than or equal to a balance of user node A account.
    [057] In (510), user node A (502) generates a set of values using HE based on one or more selected random numbers. The set of values, denoted Pf, may include proofs used to prove that the random number r in the compromise PC(r,t) is the same as or encrypted in the ciphertext OR_A(r) and OR_B(r) and the amount of transaction t in commitment PC(r,t) is the same as t encrypted in ciphertext OR_A(t) and OR_B(t). In some embodiments, four random numbers r*, t*, z1*, and z2* can be selected to compute another set of ciphertexts denoted as (C, D, E), where C = gr*ht*, D = u2r* v2z1* and E = u2t*v2z2*, where g, h, u2 and v2 are generators of an elliptic curve. Four additional proofs a, b, c and d can be calculated as a = r* + xr, b = t* + xt, c = z1* + xz1 and d = z2* + xz2, where x is a scatter function of g, h, u2, v2, C, D and E. The set of values can then be denoted as Pf = (C, D, E, a, b, c, d).
    [058] At (512), user node A (502) uses its private key to digitally sign the ciphertext (PC(r,t), OR_A(r), OR_A(t), OR_B(r), OR_B (t)), the interval proofs RP1 and RP2, and the set of values Pf. The digital signature added by user node A (502) can be used to show that the transaction is authorized by user node A (502) . The digitally signed copy is submitted to the trusted protocol network at (514).
    [059] In (516), the trust protocol node (504) verifies the digital signature using a public key of user node A (502). Trusted protocol node (504) can be a consensus node that can prove the validity of transactions in the trusted protocol network. If the trusting protocol node (504) cannot verify the digital signature using user node A's public key, the digital signature may be determined to be incorrect and the transaction may be denied. In some embodiments, the trust protocol node (504) may also include a dual anti-spend mechanism. The trust protocol node (504) can check whether the transaction has already been performed or recorded. If the transaction has already been executed, the transaction can be rejected. Otherwise, transaction validation can continue.
    [060] At (518), the trust protocol node (504) checks for one or more range probes. For example, RP1 interval proof can be used to prove that the transaction amount is greater than or equal to zero, and RP2 interval proof can be used to prove that the transaction amount is less than or equal to an account balance. of user node A (502).
    [061] At (520), the trust protocol node (504) determines whether the first transaction amount is the same as the second transaction amount, and whether the first random number is the same as the second random number based on the set of values. In some embodiments, the determination includes determining whether gahb = CTx, u2av2c = DZ_B1x and u2bv2d = EZ_B2x, where T = grh is the commitment value of the first transaction amount t, Z_B1 = u2rv2z1, Z_B2 = u2tv2z2 and where z1 and z2 are random numbers used to encrypt the second transaction amount and second random number based on the probabilistic HE scheme. If true, it can be indicated that the random number and transaction amount in the commitment are, respectively, the same random numbers and transaction amounts homomorphically encrypted using the public key of user node A (502) and user node B , and the transaction is valid.
    [062] At (522), the trust protocol node (504) updates the account balances of user node A (502) and user node B. Account balance updates can be performed based on properties of HE without revealing the account balances of user node A (502), and/or user node B.
    [063] Figure 6 represents another example of trust protocol transaction (600) based on HE according to embodiments of the present invention. As shown in the example transaction (600), a user node A (602) transfers a transaction amount t to a user node B (606). Prior to the transaction, user node A (602) has an account balance of s_A and user node B (606) has an account balance of s_B.
    [064] In some examples, the account balance s_A can be hidden using a PC-based random number r_A using the encryption schemes and transaction process described here with reference to Figure 5. The random number r_A and the account balance can be encrypted based on the OU. The ciphertext of the account balance s_A can be expressed as (S_A, R_A, Q_A) = (gr_Ahs_A, OR_A(r_A), OR_A(s_A)), where g and h can be generators of an elliptic curve to generate the PC of the balance of s_A account. Likewise, an account balance s_B from user node B (606) can be encrypted using a PC-based random number r_B. The ciphertext of account balance s_B can be expressed as (S_B, S’_B) = (gr_Bhs_B, OR_B(r_B), OR_B(s_B)).
    [065] At (604), user node A (602) can add a digital signature to the proofs used to validate the transaction and send the digitally signed copy to the trusted protocol network (608). As described here with reference to Figure 5, the proofs may include the ciphertext of the transaction amount (PC(r,t), OR_A(r), OR_A(t), OR_B(r), OR_B(t)), the one or more interval tests (RP1, RP2) and other tests (C, D, E, a, b, c, d).
    [066] After the transaction, the account balance of user node A (602) can be expressed as s_A - t, and the account balance of user node B (606) can be expressed as s_B + t. The ciphertext of the account balance of user node A (602) after the transaction can be expressed as (S_A/ T, R_A/ Y_A1, Q_A/ Y_A2), where Y_A1 = OU_A(r) and Y_A2 = OU_A(t ). The ciphertext of user node B's account balance (606) after the transaction can be expressed as (S_B * T, R_B * Z_B1, Q_B * Z_B2), where Z_B1 = OU_B(r) and Z_B2 = OU_B(t) . As S_A, S_B, R_A, R_B, Q_A, Q_B, Y_A1, Y_A2, Z_B1, Z_B2 and T are encrypted using HE with double exponential form, addition and subtraction can be performed in their encrypted form without deciphering the non-text values encoded.
    [067] Figure 7 represents an example process (700) that can be performed according to embodiments of the present invention. For clarity of presentation, the following description generally describes method (700) in the context of the other figures in this description. However, it will be understood that the example process (700) may be performed, for example, by any system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some embodiments, the steps of the example process (700) can be performed in parallel, in combination, in cycles, or in any order.
    [068] At (702), a consensus node receives, from a first account, a digitally signed copy of a commitment amount of a transaction amount to be transferred from the first account to a second account generated based on a first random number. The consensus node can also receive, from the first account, a second random number encrypted using a public key from the first account, a third random number encrypted using a public key from the second account, one or more proofs of range and a set of values generated using HE based on one or more selected random numbers. In some embodiments, commitment value is generated using the HE-based commitment scheme. In some embodiments, the second random number and the third random number are encrypted based on the deterministic HE scheme.
    [069] In some embodiments, the set of values is represented by (T1, T1', T1", r2, t2), where r2 = r1 + xr, t2 = t1 + xt, where r1 and t1 represent the one or more selected random numbers and r represents the first random number, t represents the balance transfer amount. In some examples, T1 = gr1ht1, T1' = HE_A(r1), T1" = HE_B(r1), where g and h are generators of an elliptic curve, HE_A(r1) is generated based on HE of r1 using the public key of first account, and HE_B(r1) is generated based on the HE of r1 using the public key of the second account. In some examples, x is generated based on the dispersion T1, T1’ and T1”.
    [070] At (704), the consensus node verifies a digital signature corresponding to the digitally signed copy using a public key of the first account corresponding to a private key used to generate the digital signature.
    [071] In (706), the consensus node determines whether one or more interval proofs prove that the balance transfer amount is greater than zero and less than or equal to a balance of the first account.
    [072] In (708), the consensus node determines whether the first random number, the second random number, and the third random number are the same based on the set of values. In some embodiments, the first random number, second random number, and third random number are determined to be equal if gr2ht2 = TxT1, HE_A(r2) = T'xT1' and HE_B(r2) = T"xT1", where T = grht is the commitment amount of the balance transfer amount, T' = HE_A(r) and T" = HE_B(r), HE_A(r) is generated based on HE of r using the public key of the first account, HE_B( r) is generated based on HE of r using the public key of the second account, HE_A(r2) is generated based on HE of r2 using the public key of the first account and HE_B(r2) is generated based on HE of r2 using the public key of the second account, x is generated based on scatter g, h, T1, T1' and T1”. In some embodiments, T, T’ and T” form the ciphertext for the value of the transaction amount t.
    [073] At (710), the consensus node updates the balance of the first account and a balance of the second account based on the transaction amount, if the first random number, the second random number, and the third random number are the same. In some cases, the update of the balance of the first account and the balance of the second account is carried out based on the HE.
    [074] Figure 8 represents another example of a process (800) that can be performed according to embodiments of the present invention. For clarity of presentation, the following description generally describes process example 800 in the context of the other figures in this description. However, it will be understood that the example process (800) may be performed, for example, by any system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some embodiments, the steps of process example 800 may be performed in parallel, in combination, in cycles, or in any order.
    [075] At (802), a consensus node receives, from a first account, a digitally signed copy of a commitment value of a first transaction amount for a transfer from a first account to a second account. In some examples, the digitally signed copy of the commitment value is generated based on a first random number. The consensus node also receives the first transaction amount and the first random number encrypted using a public key from the first account, a second amount from the balance transfer, and a second random number encrypted using a public key from the second account, one or more proofs range and a set of values generated using HE based on one or more selected random numbers. In some embodiments, the commitment value is generated using the PC schema. In some embodiments, the first balance transfer amount and the first random number are encrypted using the first account's public key based on a probabilistic HE algorithm. In some examples, the second balance transfer amount and a second random number are encrypted using the second account's public key based on the probabilistic algorithm HE. In some embodiments, the probabilistic HE algorithm is an Okamoto-Uchiyama HE algorithm.
    [076] In some embodiments, the set of values is represented by (C, D, E, a, b, c, d), where a = r* + xr, b = t* + xt, c = z1* + xz1 and d = z2* + xz2, where r*, t*, z1* and z2* represent the one or more selected random numbers, r represents the first random number, t represents the first balance transfer amount, C = gr* ht*, D = u2r*v2z1*, E = u2t*v2z2*, g, h, u2 and v2 are generators of an elliptic curve and x is generated based on the dispersion C, D and E.
    [077] At (804), the consensus node verifies a digital signature corresponding to the digitally signed copy using a public key of the first account corresponding to a private key used to generate the digital signature.
    [078] At (806), the consensus node determines whether one or more interval proofs prove that the balance transfer amount is greater than zero and less than or equal to a balance of the first account.
    [079] At (808), the consensus node determines whether the first amount is the same as the second amount, and whether the first random number and the second random number are the same based on the set of values. In some embodiments, the first amount and second amount are determined to be equal, and the first random number and second random number are determined to be equal, if gahb = CTx, u2av2c = DZ_B1x and u2bv2d = EZ_B2x, where T = grh is the value balance transfer amount commitment, Z_B1 = u2rv2z1, Z_B2 = u2tv2z2. In some examples, z1 and z2 are random numbers used to encrypt the second amount of transactions and the second random number based on the probabilistic HE scheme.
    [080] At (810), the consensus node updates a balance of the first account and a balance of the second account based on the first amount of the balance transfer, if the first amount and the second amount are the same, and the first number random and the second random number are the same. In some cases, the update of the balance of the first account and the balance of the second account is carried out based on the HE.
    [081] The achievements of the subject matter described in this descriptive report can be implemented in order to achieve particular advantages or technical effects. For example, embodiments of the present invention allow the account balance and transaction amount of the trust protocol nodes to be private during transactions. The funds transfer recipient does not need to confirm the transaction or use a random number to verify a commitment, transaction validation may be non-interactive. A trust protocol node can validate the transaction based on the HE and commitment schemes to allow proof of zero knowledge.
    [082] The described methodology allows for the improvement of account/data security of various mobile computing devices. Account balance and transaction amounts can be encrypted based on HE and hidden by commitment schemes. As such, a consensus node can update account balances in the ledger after the transaction based on the properties of the HE, without revealing the account's actual account balance. As the random number does not need to be sent to a recipient to confirm the transaction, the risk of data leakage can be reduced and less computing and memory resources need to be used to manage the random number.
    [083] The achievements and operations described in this specification may be implemented in digital electronic circuits, or in computer software, firmware or hardware, including the structures disclosed in this specification or in combinations of one or more of them. Operations may be implemented as operations performed by a data processing apparatus on data stored on one or more computer readable storage devices or received from other sources. A data processing apparatus, computer or computing device may encompass data processing apparatus, devices and machines, including, for example, a programmable processor, a computer, a system on a chip, or various or combinations of the foregoing. The apparatus may include special purpose logic circuitry, for example, a central processing unit (CPU), a field-programmable gate network (FPGA), or an application-specific integrated circuit (ASIC). The apparatus may also include code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system (e.g. , an operating system or a combination of operating systems), a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The appliance and execution environment can realize various infrastructures of different computing models, such as web services, distributed computing infrastructures, and grid computing infrastructures.
    [084] A computer program (also known, for example, as a program, software, software application, software module, software unit, script, or code) may be written in any form of programming language, including compiled languages or interpreted, declarative or procedural languages, and can be implemented in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A program can be stored in a part of a file that contains other programs or data (for example, one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in several coordinated files ( for example, files that store one or more modules, subprograms, or pieces of code). A computer program can run on one computer or on multiple computers that are located in one location or distributed in multiple locations and interconnected by a communication network.
    [085] Processors for executing a computer program include, by way of example, general and special purpose microprocessors, and any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from read-only memory or random access memory, or both. The essential elements of a computer are a processor to perform actions according to instructions and one or more memory devices to store instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data. A computer can be embedded in another device, for example, a mobile device, a personal digital assistant (PDA), a game console, a Global Positioning System (GPS) receiver or a portable storage device. Devices suitable for storing computer program instructions and data include non-volatile memory, memory media and devices, including, by way of example, semiconductor memory devices, magnetic disks, and magneto-optical disks. Processor and memory can be supplemented by, or incorporated into, special purpose logic circuitry.
    [086] Mobile devices may include handsets, user equipment (EU), mobile phones (eg smart phones), tablets, wearable devices (eg smart watches and smart glasses), devices implanted within the human body (eg biosensors, cochlear implants) or other types of mobile devices. Mobile devices can communicate wirelessly (for example, using radio frequency (RF) signals) to various communication networks (described below). Mobile devices can include sensors to determine characteristics of the mobile device's current environment. Sensors can include cameras, microphones, proximity sensors, GPS sensors, motion sensors, accelerometers, ambient light sensors, humidity sensors, gyroscopes, compasses, barometers, fingerprint sensors, facial recognition systems, RF sensors ( eg WiFi and cellular radio), thermal sensors or other types of sensors. For example, cameras can include a forward-facing or backward-facing camera with moving or fixed lenses, a flash, an image sensor, and an image processor. The camera may be a megapixel camera capable of capturing details for facial and/or iris recognition. The camera, together with a data processor and authentication information stored in memory or accessed remotely, can form a facial recognition system. The facial recognition system or one or more sensors, eg microphones, motion sensors, accelerometers, GPS sensors or RF sensors, can be used for user authentication.
    [087] To provide interaction with a user, embodiments can be implemented on a computer with a display device and a data input device, for example, a liquid crystal display (LCD) or organic emitting diode display of light (OLED) / virtual reality (VR) / augmented reality (AR) to display information to the user and a touch screen, keyboard and pointing device by which the user can input data to the computer. Other types of devices can also be used to provide interaction with a user; for example, the feedback provided to the user may be any form of sensory feedback, for example, visual feedback, auditory feedback, or tactile feedback; and user input can be received in any form, including acoustic, speech or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, sending web pages to a web browser on a user's client device in response to requests received from the web browser.
    [088] Embodiments may be implemented using computing devices interconnected by any form or means of wired or wireless digital data communication (or combination thereof), for example, a communication network. Examples of interconnected devices are a client and a server that are usually remote from each other and that normally interact through a communication network. A customer, for example, a mobile device, can carry out transactions itself, with a server or through a server, for example, performing purchase, sale, payment, delivery, shipment or loan transactions, or by authorizing them. Such transactions can be real-time, so that an action and a response are temporarily close together; for example, an individual perceives the action and the response occurring substantially simultaneously, the time difference for a response after the individual's action is less than 1 millisecond (ms) or less than 1 second (s), or the response is without delay intentional, considering the processing limitations of the system.
    [089] Examples of communication networks include a local area network (LAN), a radio access network (RAN), a metropolitan area network (MAN) and a wide area network (WAN). The communication network can include all or part of the Internet, another communication network or a combination of communication networks. Information can be transmitted over the communication network in accordance with various protocols and standards, including Long Term Evolution (LTE), 5G, IEEE 802, Internet Protocol (IP) or other protocols or combinations of protocols. The communication network can transmit voice, video, biometric or authentication data or other information between connected computing devices.
    [090] Features described as separate realizations can be implemented, in combination, in a single implementation, while features described as a single implementation can be implemented in several realizations, separately or in any suitable sub-combination. Operations described and claimed in a specific order should not be understood as requiring the specific order, nor that all illustrated operations be performed (some operations may be optional). As appropriate, multitasking or parallel processing (or a combination of multitasking and parallel processing) can be performed.
    权利要求:
    Claims (9)
    [0001]
    1. METHOD (800) IMPLEMENTED BY COMPUTER, performed by a consensus node (304) of a trusted protocol network (408, 608) (blockchain), characterized by comprising: receiving (802), from a first account :a digitally signed copy of a commitment amount of a first amount of a transaction amount to be transferred from a first account to a second account generated based on a first random number, the first balance transfer amount and the first number random encrypted using a public key of the first account based on the probabilistic homomorphic (HE) encryption algorithm, a second balance transfer amount and a second random number, the second amount and second random number being encrypted using a public key the second counts based on homomorphic encryption algorithm, one or more range proofs; and a set of generated values based on one or more selected random numbers; verifying (804) a digital signature corresponding to the digitally signed copy using a second public key of the first account corresponding to a private key used to generate the digital signature; ) that one or more interval tests prove that the balance transfer amount is greater than zero and less than or equal to a balance of the first account; determine (808) whether the first amount and the second amount are the same and whether the first random number and second random number are the same based on first and second encrypted quantities, first and second encrypted random numbers, and set of values; and update (810) the first account balance and a second account balance based on the first balance transfer amount if the first amount and second amount are the same and the first random number and second random number are the same, in that the selected random numbers are represented by r*, t*, z1* and z2* and the selected random numbers are used to generate a, b, c, d, C, D and E where a = r* + xr, b = t* + xt, c = z1* + xz1, and d = z2* + xz2, C = gr*ht*, D = u2r*v2z1*, E = u2t*v2z2*, where r is the first random number, t is the first balance transfer amount, z1 and z2 are random numbers used to encrypt the second balance transfer amount and the second random number, x is a scatter value generated based on C, D, E , eg, and where h, u2 and v2 are generators of an elliptic curve.
    [0002]
    2. METHOD IMPLEMENTED BY COMPUTER (800), according to claim 1, characterized in that the commitment value is generated using a commitment scheme that is homomorphic.
    [0003]
    3. METHOD IMPLEMENTED BY COMPUTER (800), according to claim 2, characterized in that the commitment scheme is a Pedersen commitment scheme.
    [0004]
    4. METHOD IMPLEMENTED BY COMPUTER (800), according to claim 1, characterized in that the probabilistic homomorphic encryption algorithm is an Okamoto-Uchiyama homomorphic encryption algorithm.
    [0005]
    5. METHOD IMPLEMENTED BY COMPUTER (800), according to claim 1, characterized in that the set of values is additionally generated based on C, D and E.
    [0006]
    6. COMPUTER IMPLEMENTED METHOD (800) according to claim 5, characterized in that the first amount and the second amount are determined to be the same and the first random number and the second random number are determined to be the same based on the probabilistic homomorphic cryptography properties.
    [0007]
    7. COMPUTER IMPLEMENTED METHOD (800), according to claim 6, characterized in that the first amount and the second amount are determined to be the same and the first random number and the second random number are determined to be the same if gahb = CTx, u2av2c = DZ_B1x, and u2bv2d = EZ_B2x, where T = grh is the commitment amount of the balance transfer amount, Z_B1 = u2rv2z1, Z_B2 = u2tv2z2.
    [0008]
    8. METHOD IMPLEMENTED BY COMPUTER (800), according to claim 1, characterized by updating the balance of the first account and a balance of the second account being performed based on homomorphic encryption.
    [0009]
    9. SYSTEM FOR IMPLEMENTING A METHOD, characterized by comprising: one or more computing devices (120); and one or more computer readable storage devices coupled to the computing device (120) and having instructions stored therein which, when executed by the one or more computing devices (120), cause the one or more computing devices (120) perform operations comprising:receive (802), from a first account:a digitally signed copy of a commitment amount of a first amount of a transaction amount to be transferred from a first account to a second account generated based on a first random number, the first balance transfer amount and the first random number encrypted using a public key of the first account based on the probabilistic homomorphic (HE) encryption algorithm, a second balance transfer amount and a second random number, where the second amount and second random number are encrypted using a public key of the second account based on the algorithm homomorphic cryptography, one or more range proofs; and a set of generated values based on one or more selected random numbers; verifying (804) a digital signature corresponding to the digitally signed copy using a second public key of the first account corresponding to a private key used to generate the digital signature; ) that one or more interval tests prove that the balance transfer amount is greater than zero and less than or equal to a balance of the first account; determine (808) whether the first amount and the second amount are the same and whether the first random number and second random number are the same based on first and second encrypted quantities, first and second encrypted random numbers, and set of values; and update (810) the first account balance and a second account balance based on the first balance transfer amount if the first amount and second amount are the same and the first random number and second random number are the same, in that the selected random numbers are represented by r*, t*, z1* and z2* and the selected random numbers are used to generate a, b, c, d, C, D and E where a = r* + xr, b = t* + xt, c = z1* + xz1, and d = z2* + xz2, C = gr*ht*, D = u2r*v2z1*, E = u2t*v2z2*, where r is the first random number, t is the first balance transfer amount, z1 and z2 are random numbers used to encrypt the second balance transfer amount and the second random number, x is a scatter value generated based on C, D, E , eg, and where h, u2 and v2 are generators of an elliptic curve.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112019008148B1|2021-08-10|METHOD IMPLEMENTED BY COMPUTER AND SYSTEM FOR IMPLEMENTING A METHOD
    BR112019008151A2|2019-09-10|computer-implemented method, non-transient computer-readable storage medium, and system
    BR112019008160B1|2021-08-24|COMPUTER IMPLEMENTED METHOD EXECUTED BY A CONSENSUS NODE OF A BLOCK CHAIN NETWORK, COMPUTER-READABLE STORAGE MEDIA, AND SYSTEM TO IMPLEMENT A METHOD
    KR20200079219A|2020-07-02|Blockchain data protection based on general account model and homogeneous encryption
    CN110402561B|2021-11-23|Block chain data protection based on general account model and homomorphic encryption
    BR112019008171A2|2019-09-10|computer-implemented method for validating blockchain transactions based on account templates, computer readable storage media, and system
    BR112019008174A2|2019-09-10|computer-implemented method, computer-readable, non-transient storage medium, and system
    BR112019008140A2|2019-09-10|computer-implemented method, non-transient computer-readable storage medium, and system
    同族专利:
    公开号 | 公开日
    EP3545483A2|2019-10-02|
    WO2019072264A2|2019-04-18|
    WO2019072264A3|2019-08-22|
    TWI695613B|2020-06-01|
    AU2018348317A1|2020-05-21|
    PH12019500898A1|2019-11-11|
    ZA201902554B|2019-12-18|
    MX2019004656A|2019-08-12|
    BR112019008148A2|2019-09-10|
    EP3545483B1|2021-04-28|
    AU2018348317B2|2020-05-28|
    PH12019500898B1|2019-11-11|
    CN110073633A|2019-07-30|
    US10664835B2|2020-05-26|
    CA3041200A1|2019-04-18|
    SG11201903553VA|2019-05-30|
    KR102215245B1|2021-02-16|
    KR20200054128A|2020-05-19|
    ES2881319T3|2021-11-29|
    EP3545483A4|2020-01-08|
    US20190251554A1|2019-08-15|
    JP2020502864A|2020-01-23|
    JP2021140156A|2021-09-16|
    CA3041200C|2020-07-14|
    RU2727161C1|2020-07-21|
    TW202019121A|2020-05-16|
    PL3545483T3|2021-10-25|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US7434726B2|2006-05-15|2008-10-14|Pitney Bowes Inc.|Method and system for postdating of financial transactions|
    JP5578754B2|2007-01-22|2014-08-27|日本電信電話株式会社|Encryption conversion method and apparatus, and program|
    US20090327141A1|2007-04-18|2009-12-31|Rabin Michael O|Highly efficient secrecy-preserving proofs of correctness of computation|
    WO2011088912A1|2010-01-22|2011-07-28|International Business Machines Corporation|Unlinkable priced oblivious transfer with rechargeable wallets|
    US8861716B2|2010-03-30|2014-10-14|International Business Machines Corporation|Efficient homomorphic encryption scheme for bilinear forms|
    US20120317034A1|2011-06-13|2012-12-13|Microsoft Corporation|Transparent virtual currency using verifiable tokens|
    US10096008B2|2012-09-10|2018-10-09|Mastercard International Incorporated|Methods and systems for processing electronic disbursements|
    CN107408174B|2015-01-30|2021-10-01|E·马伊姆|System and method for managing networking commitments for secure entities|
    WO2016200885A1|2015-06-08|2016-12-15|Blockstream Corporation|Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction|
    US10791123B2|2015-11-25|2020-09-29|Yaron Gvili|Selectivity in privacy and verification with applications|
    US10333715B2|2016-11-14|2019-06-25|International Business Machines Corporation|Providing computation services with privacy|
    WO2018115567A1|2016-12-19|2018-06-28|Nokia Technologies Oy|Method and apparatus for private data transfer between parties|
    CN106910072A|2017-02-15|2017-06-30|捷德（中国）信息科技有限公司|Digital cash management method and system|
    CN107240018A|2017-07-25|2017-10-10|成都励睿德企业管理有限公司|A kind of method and system for being used to pay tranaction costs in block chain network|
    CN108418783B|2017-09-01|2021-03-19|矩阵元技术（深圳）有限公司|Method and medium for protecting privacy of intelligent contracts of block chains|
    CN108021821A|2017-11-28|2018-05-11|北京航空航天大学|Multicenter block chain transaction intimacy protection system and method|
    WO2019109003A1|2017-11-30|2019-06-06|Visa International Service Association|Blockchain system for confidential and anonymous smart contracts|
    CN108335106A|2018-01-24|2018-07-27|深圳壹账通智能科技有限公司|The more account books of Zero Knowledge based on block chain exchange transfer account method, device and storage medium|
    CN108377189B|2018-05-09|2021-01-26|深圳壹账通智能科技有限公司|Block chain user communication encryption method and device, terminal equipment and storage medium|
    CN108632293B|2018-05-16|2021-08-06|山东建筑大学|Building equipment Internet of things system and method based on block chain technology|
    CN108764874B|2018-05-17|2021-09-07|深圳前海微众银行股份有限公司|Anonymous transfer method, system and storage medium based on block chain|
    CN109584055B|2018-09-20|2020-07-03|阿里巴巴集团控股有限公司|Transaction method and device based on block chain and remittance side equipment|US10771237B2|2017-01-20|2020-09-08|Enveil, Inc.|Secure analytics using an encrypted analytics matrix|
    US10693627B2|2017-01-20|2020-06-23|Enveil, Inc.|Systems and methods for efficient fixed-base multi-precision exponentiation|
    US20180212753A1|2017-01-20|2018-07-26|Enveil, Inc.|End-To-End Secure Operations Using a Query Vector|
    US11196541B2|2017-01-20|2021-12-07|Enveil, Inc.|Secure machine learning analytics using homomorphic encryption|
    US10902133B2|2018-10-25|2021-01-26|Enveil, Inc.|Computational operations in enclave computing environments|
    US10817262B2|2018-11-08|2020-10-27|Enveil, Inc.|Reduced and pipelined hardware architecture for Montgomery Modular Multiplication|
    CN110020541B|2019-04-19|2020-11-03|北京理工大学|Reputation evaluation method and system based on block chain privacy protection|
    CN110224985A|2019-05-07|2019-09-10|平安科技（深圳）有限公司|The method and relevant apparatus of data processing|
    CN110276684B|2019-05-20|2021-04-23|创新先进技术有限公司|Receipt storage method and node combining transaction type and event function type|
    US10778410B2|2019-06-18|2020-09-15|Alibaba Group Holding Limited|Homomorphic data encryption method and apparatus for implementing privacy protection|
    CN110348231B|2019-06-18|2020-08-14|阿里巴巴集团控股有限公司|Data homomorphic encryption and decryption method and device for realizing privacy protection|
    CN110830452A|2019-10-22|2020-02-21|全链通有限公司|Block chain-based electronic bidding method, device and storage medium|
    CN110766407A|2019-10-22|2020-02-07|全链通有限公司|Transaction verification method, accounting node and medium based on block chain|
    CN110768979B|2019-10-22|2021-12-24|吕春芳|Formica algorithm-based block chain big data processing method and system|
    CN110730187A|2019-10-22|2020-01-24|全链通有限公司|Transaction verification method, accounting node and medium based on block chain|
    CN111194066B|2020-01-10|2022-02-11|中国联合网络通信集团有限公司|Base station alliance method and device|
    EP3794537A4|2020-02-03|2021-05-26|AlipayInformation Technology Co., Ltd.|Blockchain-based trustable guarantees|
    SG11202013136SA|2020-02-03|2021-01-28|Alipay Hangzhou Information Technology Co Ltd|Blockchain-based trustable guarantees|
    EP3794484A4|2020-02-03|2021-05-05|AlipayInformation Technology Co., Ltd.|Blockchain-based trustable guarantees|
    EP3799644A4|2020-02-03|2021-06-09|AlipayInformation Technology Co., Ltd.|Blockchain-based trustable guarantees|
    EP3794773A4|2020-02-03|2021-05-05|AlipayInformation Technology Co., Ltd.|Blockchain-based trustable guarantees|
    EP3794483A4|2020-02-03|2021-04-28|AlipayInformation Technology Co., Ltd.|Blockchain-based trustable guarantees|
    CN112001731A|2020-04-02|2020-11-27|支付宝信息技术有限公司|Block chain account balance deposit certificate and recovery method and device|
    DE102020004122A1|2020-07-08|2022-01-13|Giesecke+Devrient Gesellschaft mit beschränkter Haftung|PAYMENT SYSTEM, COIN REGISTER, SUBSCRIBER UNIT, TRANSACTION REGISTER, TRACK REGISTER AND METHOD FOR PAYING WITH ELECTRONIC COIN RECORDS|
    法律状态:
    2021-01-19| B25A| Requested transfer of rights approved|Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-02-09| B25A| Requested transfer of rights approved|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-06-29| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2021-08-10| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 07/11/2018, OBSERVADAS AS CONDICOES LEGAIS. |
    优先权:
    申请号 | 申请日 | 专利标题
    PCT/CN2018/114344|WO2019072264A2|2018-11-07|2018-11-07|Blockchain data protection using homomorphic encryption|
    [返回顶部]